1 INTRODUCTION *

2 NEW TERMINOLOGY *

3 SECURITY CONTROLS AND CERTIFICATION LEVELS *

4 CERTIFICATION AND ACCREDITATION PROCESS *

5 ANALYSIS *

FIGURES

TABLES

APPENDICES

A. RISK ASSESSMENT SUMMARY TABLE

1. INTRODUCTION

NIST Special Publication 800-37 (Draft), Guidelines for Security Certification and Accreditation of IT Systems, was published on October 28, 2002. This document is a synopsis of that publication, and is targeted to individuals with previous exposure to the Certification and Accreditation (C&A) process through the National Information Assurance Certification and Accreditation Process (NIACAP), or the Defense Information Technology System Certification and Accreditation Process (DITSCAP). It assumes a reader’s knowledge of information assurance terminology, general procedures, and best practices.



Figure 1 NIST 800-37 Environment

 

2. NEW TERMINOLOGY

The following table lists terminology found in NIST SP 800-37 that may be unfamiliar to information assurance personnel previously involved in C&A activities:

Control Class	A grouping of security controls, organized by control families, that all fall under the same broad category. There are three general classes of security controls: (1) Management, (2) Operational and (3) Technical. See SP 800-18, 800-37, and 800-53.
Control Family	A grouping of security controls that fall under the same more specific category, which are often interrelated and interdependent, and which should be considered as a group.
Critical Elements	Important security-related focus areas for the system with each critical element addressed by one or more security controls.
Defense-in-Depth	Two fold approach to securing an IT system: (1) layering security controls within a given IT asset and among assets, and (2) ensuring appropriate robustness of the solution as determined by the relative strength of the security controls and the confidence that the controls are implemented correctly, are effective in their application, and will perform as intended. The combination produces layers of technical and non-technical controls that ensures the confidentiality, integrity and availability of the information and IT system resources.
Entry-level Certification	The most basic security certification level, appropriate for systems engendering low levels of concern for confidentiality, integrity, and availability.
Exposure	A measure of the potential risk to an IT system from both external and internal threats.
External System Exposure	Relates to: (1) the method by which users access the system (dedicated, intranet, internet, wireless), (2) the existence of backend connections to the system and to what the backend systems are connected, and (3) the number of users who access the system.
Internal System Exposure	Relates to the types of individuals that have authorization to access the system and the information the system stores, processes and transmits. It includes such items as individual security background assurances and/or clearance levels, access approvals, and need-to-know.
Levels of Concern	An expression of the criticality/sensitivity of an IT system in the areas of confidentiality, integrity, availability, and exposure, expressed qualitatively as HIGH, MODERATE or LOW. The level of concern indicates the extent to which security controls must be applied to an IT system based on risk, threat, vulnerability, system interconnectivity considerations, and information assurance needs.
Mid-level Certification	More stringent than an entry-level certification, this certification level is appropriate for systems engendering moderate levels of concern for confidentiality, integrity, and/or availability.
Security Certification Level	A combination of techniques and procedures used during C&A process to verify the correctness and effectiveness of security controls in an IT system. Security certification levels, identified as SCL-1, SCL-2, or SCL-3, represent increasing levels of intensity and rigor in the verification process and include such techniques as reviewing and examining documentation, interviewing personnel, conducting demonstrations and exercises, conducting functional, regression, and penetration testing, and analyzing system design documentation.
Top-level Certification	More stringent than the mid-level certification, this certification level is appropriate for systems engendering high levels of concern for confidentiality, integrity, and/or availability.
Verification Procedure Refinements	Verification procedures that have been tailored to the specific system and environment where the system is deployed for operation (or in the case of new systems, where the system is intended to be deployed for operation

 

3. SECURITY CONTROLS AND CERTIFICATION LEVELS
1. Characterizing the System

In order to select the proper security controls (discussed below) for the C&A process, the system must be accurately characterized. Characterizing includes the following:

• Examination of criticality/sensitivity of the system and information possessed, stored and transmitted;
• Assessment of exposure, both external and internal;
• Assignment of the appropriate level of concern.

1. System Criticality/Sensitivity

This is addressed by analyzing the system requirements for confidentiality, integrity and availability. Analysis determines the value of the system (major factor in risk assessment).

2. System Exposure

This is a measure of potential risk from both internal and external sources (see definitions above). The method of determination for system exposure differs depending on levels of concern for confidentiality/integrity.

1. External System Exposure

This relates to the following considerations:

• Method by which users access the system, including dedicated connections, Intranet, Internet, and wireless network;
• Backend Connections;
• Number of users having authorized access to the system.

1. Internal System Exposure

Internal system exposure is considered for:

• Systems processing classified national security information;
• Sensitive But Unclassified (SBU) information with high confidentiality requirements;
• Systems with high integrity requirements;

It relates to the types of individuals having access to the system and includes:

• Individual security background assurances and/or clearance levels;
• Access approval;
• Need-to-know.

1. Levels of Concern

Levels of concern are evaluations of individual system requirements based upon tolerance for:

• Unauthorized disclosure or compromise for confidentiality;
• Unauthorized modification or destruction for integrity;
• Delay in processing, transmission, storage; or disruption or denial of service for availability.

Values for levels of concern are assigned as LOW, MODERATE, or HIGH. The value for the level of concern for confidentiality in classified IT systems is always considered HIGH, although values for levels of concern for Integrity and Availability in some classified IT systems may be HIGH, MODERATE or LOW

1. External System Exposure

In addition to levels of concern, exposure must be considered in selecting security controls against which the C&A evaluation is conducted. External system exposure values are designated LOW, MEDIUM or HIGH.

External system exposure reviews:

1. Access method;
2. Backend connections;
3. Number of users.

Each is analyzed and valued separately, and the highest value established becomes the value for the external system exposure analysis.

1. Internal System Exposure

Internal system exposure analysis is considered only for systems in which there is a HIGH level of concern for CONFIDENTIALITY.

There are four case scenarios relating to levels of concern for internal exposure which consider:

1. Clearance
2. Access Approval
3. Need-To-Know

Analysis of the four case scenarios leads to a level of concern determination of LOW, MEDIUM or HIGH (case 2 and case 3 both lead to a determination of MODERATE).

1. Security Controls

Security controls will be determined by application of values established in the above analysis process. NIST expects to publish the security controls in Spring 2003 as NIST SP 800-53, Minimum Security Controls for Federal Information Systems. The draft publication of NIST SP 800-37 does not distinguish security controls from security requirements (SRTM) as recognized in present NIACAP or DITSCAP processes, and does not demonstrate the nexus between requirements and controls. However, NIST SP 800-37 does present a definition of each, which is reproduced in Section 4.1.3 of this document.

1. Organization of Security Controls

NIST SP 800-53 will organize security controls into (1) Classes and (2) Families

1. Classes

The three general classes of security controls are:

1. Management
2. Operational
3. Technical

1. Families

Within each class, families are defined covering the following topic areas:

1. Risk management
2. System Development and Acquisition
3. Configuration Management
4. System Interconnections
5. Personnel Security
6. Education and Training
7. Physical and Environmental Protection
8. Media Protection
9. Contingency Planning
10. Hardware and System Software Maintenance
11. System and Data Integrity
12. Documentation
13. Incident Response Capability
14. Identification and Authentication
15. Logical Access
16. Audit
17. Communications

Security controls in each family will be grouped by critical elements, representing important security-related focus areas. Each critical element may be addressed by one or more security controls. That is, a particular family (as indicated above) may have several critical elements, and there may be several security controls associated with any particular critical element within a selected family.

1. Naming Convention

Security controls will be named in a unique manner which will describe the (1) Family and (2) The number of the particular security control within the family.

As reflected in the NIST SP 800-37 example below, PS-8 would represent the Personnel Security family, and the eighth distinct security control in the Personnel Control family

Additional designators will be employed as extensions of the basic security control name.

1. Level of Concern Designator

The level of concern designator will be either M for moderate or H for high. The level of concern of LOW is not included because the low level of concern is part of the basic security control package, which is applicable to all systems. The designator notations of M and H will be applicable to systems projecting elevated levels of concern in the C&A process.

2. Security Factor Designator

The security factor designator in the naming convention represents:

1. C for confidentiality
2. I for integrity
3. A for availability

1. Control Number Designator

The numeric value in the security control naming convention indicates the control number in a particular family.

??

Insert Fig.3.1 (Naming convention), p24, here

??

1. Security Control Selection

After levels of concern have been determined for Confidentiality, Integrity and Availability, as well as System Exposure (external, and internal if applicable), the appropriate security controls are selected from the pre-defined controls in NIST SP 800-53.

Security controls in NIST SP 800-53 will be minimum controls recommended for systems requiring basic, moderate or high degrees of protection. Additional security controls may be necessary to meet specific requirements of the particular IT system undergoing C&A.

1. Selection Process

The selection process is accomplished in three steps:

1. Selection of the standard package of security controls representing the baseline set of controls for all federal IT systems.
2. Creation of a specialized set of supplemental security controls based upon determined higher levels of concern for confidentiality, integrity and availability.
3. Addition of agency-specific or technology-driven security controls, as appropriate.

1. Supplemental Controls Selection

Following selection of the baseline security controls for all federal systems, NIST SP 800-53 must be reviewed to determine supplemental security controls to be included.

Each family within the three classes (management, operational, and technical) should be examined.

For example, an agency with a stated moderate level of concern for confidentiality, high level of concern for integrity, and low level of concern for availability, (i.e., C=M, I=H, A=L), would select the standard package of basic controls and then look through each family for applicable controls with any of the following extensions to the basic control name: MC, MCI, MCA, MCIA, HI, HCI, HIA, HCIA. This process ensures that every security control addressing moderate confidentiality and high integrity is selected for the supplemental package. Controls for low availability are covered in the standard package of basic controls.

1. Security Control Selection Adjustment

Management (undefined by NIST SP 800-37) may make adjustments to security controls selection for a C&A through risk-based decisions to substitute equivalent controls, waivers of recommended security controls, or enhancement of security controls.

Any substitution, waiver or enhancement of security controls should be noted in the agency’s security plan, along with support rationale and support documentation.

1. Security Certification Levels

There are three security certification levels defined in NIST SP 800-37. These certification levels relate to the rigor and intensity in the application of the verification techniques to determine compliance with security requirements and to demonstrate correctness and effectiveness of the security controls.

 

1. Security Certification Level 1 (SCL-1)

SCL-1 is the entry- level certification for information systems, and is appropriate for:

Low levels of concern for confidentiality, integrity and/or availability;

At the discretion of management, moderate to high levels of concern for confidentiality, integrity and/or availability, and low to moderate concerns for system exposure.

SCL-1 certifications are low intensity activities that can be accomplished with minimal resources using simple techniques involving personal interviews, documentation reviews, and observations.

2. Security Certification Level 2 (SCL-2)

SCL-2 is the mid-level certification for IT systems and is appropriate for:

• Moderate levels of concern for confidentiality, integrity and/or availability;
• At the discretion of management, high levels of concern for confidentiality, integrity and/or availability, and low to moderate levels of concern for system exposure.

SCL-2 certifications call for independent assessments of IT systems by adding more substantial certification techniques to the SCL-1 verification procedures. SCL-2 certifications are moderate-intensity activities that may be accomplished using standard, commercially available assessment tools, and verification techniques such as personnel interviews, documentation reviews, observations, demonstrations, and limited security testing and evaluation (ST&E)

1. Security Certification Level 3 (SCL-3)

SCL-3 is the top-level certification for IT systems and is appropriate for systems with:

• High levels of concern for confidentiality, integrity and availability

SCL-3 techniques call for independent assessments, build on SCL-1 and SCL-2 verification techniques, and employ the most rigorous verification methods. SCL-1 certifications are high intensity, and require substantial resources for system design analysis, extended functional testing with test coverage analysis, regression analysis/testing, demonstrations, exercises and penetration testing with Red Team option.

??

Insert Fig. 3.4, Certification levels, p.28 her

??

1. Certification Level Selection Process
1. Initial Selection

Determine levels of concern for confidentiality, integrity, and availability.

1. Select the INITIAL Certification Level:

• If ANY level of concern is HIGH, SCL-3 is selected;
• If no high levels of concern, and any is MODERATE, SCL-2 is selected;
• If all levels of concern are LOW, SCL-1 is selected.

1. Certification Level Adjustment

Under certain parameters, system security levels (SLCs) may be adjusted following evaluation of system exposure (external for SCL-2 and SCL-1; external and internal for SCL-3). All adjustments require documented management decision.

If level of concern for confidentiality is MODERATE or LOW, only external system exposure is considered for certification adjustment. If the level of concern for confidentiality is HIGH, internal system exposure also must be considered.

If level of concern for external system exposure is HIGH, no certification adjustment is necessary.

1. Exposure Considerations (External and Internal)

If the level of concern for external system exposure is MODEDRATE, the initial certification level, at management discretion, may be lowered one level; that is:

• SCL-3 to SCL-2, or
• SCL-2 to SCL-1

If the level of concern for external system exposure is LOW, the initial certification level, at management discretion, may be lowered up to two levels, that is

• SCL-3 to SCL-2, or to SCL-1, or

• SCL-2 to SCL-1

IF THE LEVEL OF CONCERN FOR CONFIDENTIALITY AND/OR INTEGRITY IS HIGH, both external system exposure and internal system exposure are considered in making possible adjustments. This is known as total system exposure.

** (NIST SP 800-37 is in conflict: Section 3.3.4 addresses confidentiality as the only qualifier, and Section 3.3.5 (Summary) uses "confidentiality and/or integrity" as qualifiers. However, from the reading of the entire NIST SP 800-37, it appears that a high level of concern for integrity also should mandate a "total system exposure" analysis.)

1. Total System Exposure

When the level of concern for confidentiality and/or integrity is HIGH, the total system exposure is employed to determine if the initial certification level may be adjusted downward.

The level of concern for total system exposure is evaluated as HIGH, MEDIUM or LOW

Independent evaluations are conducted on:

1. External system exposure (H, M, L), and
2. Internal system exposure (H, M, L)

The highest evaluation (H, M, L) for either external or internal system exposure becomes the level of concern for total system exposure (H, M, L)

1. Adjustments Based Upon Total System Exposure

If the level of concern for total system exposure is MODEDRATE, the initial certification level, at management discretion, may be lowered one level; that is:

• SCL-3 to SCL-2, or
• SCL-2 to SCL-1

If the level of concern for total system exposure is LOW, the initial certification level, at management discretion, may be lowered up to two levels, that is

• SCL-3 to SCL-2, or to SCL-1, or
• SCL-2 to SCL-1

1. Relationship of Security Controls to Certification Levels

Security controls and certification levels are based upon the levels of concern (H, M, L) for confidentiality, integrity, and availability.

Levels of concern for system exposure (external, internal, total system) can effect the selection and adjustment of the initial security certification level, and the security controls to be tested in the C&A process.

1. Security Control Verification

NIST Special Publication 800-53A, Techniques and Procedures for the Verification of Security Controls in Federal Information Systems (NIST SP 800-53A)(due Spring 2003), will publish a complete list of verification procedures relating to the security controls published in NIST SP 800-53. These procedures will describe the specific assessment activities relating to the security controls and critical elements found in NIST SP 800-53, which will be required for the C&A to demonstrate correct and effective implementation of required security controls.

Additional ST&E procedures may be developed based upon the particular platform under testing in the C&A.

??

Insert Table 3.6 Security Controls and Verification Procedures, p 33 here

??

1. CERTIFICATION AND ACCREDITATION PROCESS

The C&A process described in NIST SP 800-37 is similar to the present DITSCAP and NIACAP processes, with four distinct phases:

1. Pre-Certification Phase
2. Certification Phase
3. Accreditation Phase
4. Post Accreditation Phase

1. Pre-Certification Phase

The pre-certification, as described in NIST 800-37, consists of verification activities grouped into tasks and subtasks. This phase consists of six tasks:

1. System Identification
2. Initiation and Scope Determination
3. Security Plan Validation
4. Initial Risk Assessment Validation
5. Security Control Validation and Identification
6. Negotiation

Much of the information needed to complete these tasks flows from the tested agency’s security plans, risk assessments, and other security related documentation. Most of the tasks and subtasks track the guidelines for system security plans found in NIST SP 800-18.

1. TASK 1: System Identification

This task validates that the agency security plan contains essential system identification information.

SUBTASK	SYSTEM INFORMATION	ACTIVITY	REFERENCE
Subtask 1.1	System Name/Title	Validate that the security plan list agency name and unique identifier for the system.	NIST SP 800-18
Subtask 1.2	Responsible Organization	Validate that the security plan lists location of the agency responsible and organizations containing end users.	NIST SP 800-18
Subtask 1.3	Contact Information	Validate that the security plan lists all contact information for appropriate management and security personnel.	NIST SP 800-18
Subtask 1.4	Assignment of Security Responsibility	Validate that the security plan list all contact information for responsible security personnel.	NIST SP 800-18
Subtask 1.5	System Boundary	Validate that the security plan describes boundary of the system for the purpose of accreditation.	NIST SP 800-18 NIST SP 800-37
Subtask 1.6	System Status	Validate that the security plan describes status of system in life cycle.	NIST SP 800-18

 

2. TASK 2: Initiation and Scope Determination

This task initiates the C&A process and determines the scope of certification. It is similar to the development of the System Security Authorization Agreement (SSAA) in the DITSCAP process, and requires the involvement and input of key personnel. General agreement is reached concerning:

• Levels of concern for confidentiality, integrity, and availability (system criticality/sensitivity)
• Levels of concern for external and internal system exposure
• Security certification level

1. TASK 3: Security Plan Validation

This task is designed to validate that the security plan:

• Provides a complete and accurate description of the IT system and operating environment
• Identifies security requirements for the system
• Delineates responsibilities and expected behavior of users

Security requirements articulate the types and levels of protection necessary for equipment, data, information, applications, and facilities to meet applicable laws, regulations, standards, instructions and/or security policies.

Security controls include the management, operational, and technical safeguards employed to protect the information in the system.

1. TASK 4: Initial Risk Assessment

This task validates the initial risk assessment, and includes identification of threats and vulnerabilities. The initial assessment provides input to a more thorough vulnerability analysis performed during the certification phase.

SUBTASK	SYSTEM INFORMATION	ACTIVITY	REFERENCE
Subtask 4.1	Threat Identification	Validate that the initial risk assessment identifies and lists potential threat-sources that could exploit system vulnerabilities.	NIST SP 800-30
Subtask 4.2	Vulnerability Identification	Validate that the initial risk assessment identifies and lists system vulnerabilities that could be exploited by potential threat sources.	NIST SP 800-30

 

2. TASK 5: Security Control Validation and Identification

This task:

• Validates that the security plan describes the security controls for the system
• Identifies any additional security controls not contained in the security plan

The security controls selection is based on the initial characterization of the system from the security plan, and any additional controls based on the initial risk assessment.

1. TASK 6: Negotiation

This task validates the information obtained during the pre-certification phase, and provides key personnel an opportunity to review the extent and scope of the C&A, and to reach final agreement on:

• Levels of concern for confidentiality, integrity and availability;
• Levels of concern for system exposure;
• Certification level;
• Security controls;
• Residual risk;
• Procedure for remainder of C&A;

1. Certification Phase

The purpose of this phase is to demonstrate through independent assessments using selected verification techniques and procedures that security controls have been implemented properly and are effective. The certification phase consists of two tasks:

• Verification Procedure Refinement, and
• Security Test and Evaluation (ST&E)

NIST SP 800-53A will distinguish between developmental and operational ST&E activities

1. TASK 7: Verification Procedure Refinement

The purpose of this task, where applicable, is to develop appropriate refinements to verification procedures to establish system-specific technical and non-technical tests. Verification procedure refinements tailor verification procedures to the specific system and environment where the system is deployed for operation or is intended to be deployed. Verification procedure refinements are created only when the procedures for security controls (NIST SP 800-53 and NIST 800-53A) are insufficient to demonstrate that the controls are correctly implemented or effective.

SUBTASK	SYSTEM INFORMATION/ OBJECTIVE	ACTIVITY	REFERENCE
Subtask 7.1	Procedure Refinement	Develop, if needed, refinements to the verification procedures associated with the basic security controls and any additional controls.	NIST SP 800-53

2. TASK 8: Security Test and Evaluation (ST&E)

The objectives of this task are to:

• Demonstrate through appropriate verification techniques, verification procedures, and procedure refinements (as needed), that the management, operational, and security controls for the IT system are implemented correctly and are effective
• Prepare the final ST&E reports based on the results of the ST&E activities

1. Accreditation Phase

• Complete final risk assessment
• Determination of residual risk
• Update security plan
• Prepare certification findings
• Issue accreditation decision

There are four tasks associated with this phase:

1. Final Risk Assessment
2. Security Plan Update
3. Certification Findings
4. Accreditation Decision

1. TASK 9: Final Risk Assessment

The purpose of this task is to determine the residual risk to the system. The certification phase describes which security controls are correctly (or incorrectly) implemented, and are effective (or in effective), and identifies partial implementation and/or missing security controls. The residual risk is documented in the final risk assessment, and describes remaining risks after appropriate mitigation has occurred. The degree of acceptable risk is determined by the DAA.

SUBTASK	SYSTEM INFORMATION/ OBJECTIVE	ACTIVITY	REFERENCE
Subtask 9.1	Final Risk Assessment	Determine the residual risk to the system through review of ST&E activities and risk mitigation.	NIST SP 800-18 NIST SP 800-30 NIST SP 800-37 NIST SP 800-53

2. TASK 10: Security Plan Update

The objective of this task is to ensure the security plan is updated based on results of ST&E and the final risk assessment.

SUBTASK	SYSTEM INFORMATION/ OBJECTIVE	ACTIVITY	REFERENCE
Subtask 10.1	Security Plan Update	Update the security plan based on review of ST&E and final risk assessment.	NIST SP 800-18 NIST SP 800-37

 

3. TASK 11: Certification Findings

The objective of this task is to prepare the final certification findings and assemble the certification package for the DAA. The certification findings also recommend to the DAA the possible implementation of additional risk mitigation actions that would mitigate residual risks.

SUBTASK	SYSTEM INFORMATION/ OBJECTIVE	ACTIVITY	REFERENCE
Subtask 11.1	Certification Findings	Prepare the final certification findings, and prepare the final certification package.	NIST SP 800-18 NIST SP 800-37

 

4. TASK 12: Accreditation Decision

The object of this task is for the DAA to review the certification package, and issue the final accreditation decision for the IT system. The residual risk must be within tolerable limits established by the DAA. The DAA makes a risk-based decision to:

1. Grant system accreditation
2. Grant an interim approval to operate
3. Deny system accreditation

1. Post-Accreditation Phase

The purpose of this phase is to monitor the status of the IT system to determine significant changes to the system configuration or to the operational/threat environment. This activity is necessary to ensure that the acceptable level of residual risk is maintained. Significant changes require reaccreditation activity. This is a continuous process. The post-accreditation phase consists of four tasks (NIST SP 800-37 states three tasks, but enumerates four tasks):

1. Risk assessment update
2. System and Environmental Update
3. Reaccreditation
4. System Disposal

1. TASK 13: Risk Assessment Update

The objective of this task is to continuously monitor, review, and assess open source and other available threat and vulnerability information. Newly identified threats and vulnerabilities may require review of:

• Levels of concern for confidentiality, integrity, availability and exposure;
• Security Controls;
• Certification level.

1. TASK 14: System and Environment Update

The object of this task is to track all modifications to the IT system or its supporting operational environment. After a system modification is completed and it is verified that the change does not affect system security, the security plan is updated. If the security of the system is affected, a reaccreditation may be required.

SUBTASK	SYSTEM INFORMATION/ OBJECTIVE	ACTIVITY	REFERENCE
Subtask 14.1	System and Environment Update	Review all modifications to the system operational environment to determine potential security impacts of such modifications.	NIST SP 800-18 NIST SP 800-37
Subtask 14.2	System and Environment Update	Update the security plan, as needed.	NIST SP 800-18 NIST SP 800-37

2. TASK 15: Reaccreditation

The objective of this task is to identify significant changes requiring affecting the system and requiring reaccreditation. Portions of the previous certification documentation and ST&E results still may be applicable, and may be reused during reaccreditation.

SUBTASK	SYSTEM INFORMATION/ OBJECTIVE	ACTIVITY	REFERENCE
Subtask 15.1	Reaccreditation	Determine the need for reaccreditation of the IT system. If reaccreditation is required, revert to pre-certification phase at TASK 1.	NIST SP 800-37

3. TASK 16: System Disposal

The objective of this task is to ensure that an IT system, at the end of the life cycle and identified for disposal, is taken out of the operational environment and disposed of in a secure manner. Three important areas of concern must be addressed:

1. Archival of information
2. Disposal of hardware, firmware and software
3. Sanitization of media

1. ANALYSIS

NIST SP 800-37 (Draft) represents an initial step by the National Institute of Standards and Technology to standardize Certification & Accreditation activity throughout federal IT systems. With the publication of this document and the additional documents to follow in Spring 2003 (NIST SP 800-53 and NIST SP 800-53A), several important issues become of interest to the information assurance community.

 

1. Guidance versus Law

The publication of NIST SP 800-37 represents, by definition, guidance in the protection of sensitive information in federal IT systems. Will it have the impact, effect and force of law in its promulgation of methodologies for Certification and Accreditation activities? A review of the Computer Security Act of 1987, OMB A-130, and GISRA would indicate that the controls addressed and enumerated in NIST SP 800-37, NIST SP 800-53, and NIST 800-53A may create a legal efficacy, but this is not conclusive.

P.L. 100-235, Computer Security Act of 1987, 01/08/1988

• Each government agency must establish computer security policy commensurate with risk and magnitude of harm resulting from loss, misuse, unauthorized access to or modification of information contained in the system.
• Each government agency must develop security plans for systems that contain sensitive information.
• Summaries of agency security plans must be included in the information resources management plan required by the Paperwork Reduction Act of 1980.
• Each government agency must provide mandatory periodic training for all persons involved in management, use, or operation of computer systems that contain sensitive information.

Office of Management and Budget, OMB Circular A-130, Management of Federal Information Resources, Executive Office of the President, Publication Services, November 2000.

• Agency inclusion of system security plans and major application plans summaries in the strategic plan required by the Paperwork Reduction Act (44 U.S.C. 3506);
• For general support systems, agencies must: assign responsibility for security; develop and implement a security plan; establish rules of behavior that delineate responsibilities and expectations for all users and state consequences for violations; review security controls at least every three years or sooner upon significant modifications; and written authorize processing before beginning or significantly changing processing in the system;
• For major applications, agencies must: assign responsibility for security, develop and implement a system security plan, perform independent review or audit of security controls at least every three years, and ensure written authorize processing for the use of the application.
• OMB A-130 further directs agencies to assure that:

P.L. 106-398, National Defense Authorization Act, Fiscal Year 2001 Title X Subtitle G, Government Information Security Reform Act, 10/30/2000

The Security Act (GISRA) amends the Paperwork Reduction Act (PRA) by enacting new subchapters on information security, and primarily addresses the program management and evaluation aspects of security. Issues addressed include Life Cycle, incident response, agency performance plans, annual agency program reviews, annual Inspector General security evaluations, and required reports to OMB. The OMB is also required to report annually to congress.

• For unclassified systems, OMB retains existing policy authority under the PRA and the Clinger-Cohen Act of 1996.
• Except for the new annual program reviews, the role of agency Inspectors General, and annual reporting requirements, GISRA essentially codifies the existing requirements of OMB A-130, Appendix III

This chronology of law and directives presents a specific issue for resolution: If a federal agency maintains a Certification & Accreditation process which complies with all other NIST or OMB security requirements, must the new NIST SP 800-37 be substituted for current procedures. Viewing NIST as guidance under these circumstances, there may be a reasonable authority and grounds to answer this question in the negative.

1. Security Requirements versus Security Controls
2. Established Department of Defense Requirements and Processes
3. Organizational Accreditation

A true determination of the impact resulting from the NIST initiative to establish standardization of the Certification and Accreditation process will be the "Assessment Program" to follow in Phase II of the effort. Subsequent to the publication of NIST SP 800-53 and NIST SP 800-53A, the NIST effort will endeavor to develop an Organizational Accreditation for those entities, both in the private and public sectors, who conduct C&A activities. The objective of this action is to give federal agencies a greater confidence in the acquisition and use of the C&A process. However, the process contemplates that organizations participating in C&A activities demonstrate a competence in the application of the new NIST standardized verification techniques and procedures. Organizational Accreditation may involve proficiency testing, and the demonstration of specialized skills in particular areas of interest. NIST envisions public workshops in Spring 2003 to discuss potential organizational accreditation models.

If Organizational Accreditation and, at least by implication, utilization of the NIST standardized process, becomes a prerequisite for bidding upon a C&A proposal, a substantive change will be affected in C&A methodology on an enterprise-wide basis. Such change would require additional training and education of Information Assurance personnel and essential modification of the C&A process, as well as enhanced alteration and development of commercial C&A tools. As a result, de facto force of law will be afforded the NIST guidance in the standardization of the C&A process.